You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
feat: Support the use of expression builder objects in settings parameter. - #5546
Let users assign expression-builder objects (and any object implementing a small protocol) directly to settings leaves — e.g. named_expressions["dp"].definition = dp instead of = str(dp) — with automatic validation, across every assignment path.
Change Summary
Generic, Fluent-agnostic protocol in the settings layer:
Added a domain-neutral protocol the settings layer talks to — settings_str (render), settings_kind (structural tag), settings_dimensions (physical dims) — plus helpers _is_settings_expression, _normalize_dimensions, _leaf_dimensions, _validate_expression_quantity, and _render_settings_expression. flobject no longer references fluent_expr or the offline.expressions package at all.
expr usable wherever an expression string is permitted:
Textual.set_state now accepts expression objects only foe whitelisted paths.
RealNumerical.set_state (covers Real/RealList) now accepts expression objects to -->> LLM suggestion: "closing the biggest gap — previously an expr there raised UnhandledQuantity".
Quantity-type checks before str conversion:
Expr base now implements settings_str (forwards to the internal fluent_expr), __settings_kind__, and __settings_dimensions__. Quantity derives dims from its units; Variable from its VariableDescriptor.dimension. fluent_expr stays as the package-internal renderer.
Impact
users assign expression-builder objects directly to settings leaves — e.g. named_expressions["dp"].definition = dp instead of = str(dp) — with automatic validation.
##Note:
When running against a live session: the dimensional check depends on ansys.units being able to resolve the leaf's SI unit string and the expression's units; anything it can't resolve is treated as "unknown" and tolerated, so it will never spuriously block a valid assignment.
Also added two parametrized tests in test_flobject_expression_integration.py implementing the requested flow — start from an expression string → parse via the builder → read the built object's quantity type → compare with the target parameter's quantity type.
For detailed plan of this please refer the issue and the tests as well
NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer TIP This summary will be updated as you push new changes.
This PR broadens direct assignment of expression-builder objects to PyFluent settings, replacing path-specific integration with a generic settings-expression protocol.
Changes:
Adds rendering, structural-kind, and physical-dimension hooks to expression objects.
Extends textual and real-valued setters with expression handling and validation before rendering.
Updates examples, integration tests, and release notes.
What changed in this PR
This PR broadens direct assignment of expression-builder objects to PyFluent settings, replacing path-specific integration with a generic settings-expression protocol.
Changes:
Adds rendering, structural-kind, and physical-dimension hooks to expression objects.
Extends textual and real-valued setters with expression handling and validation before rendering.
Updates examples, integration tests, and release notes.
File Description tests/expressions/test_fluent_smoke.py Extends live named-expression assignment checks. tests/expressions/test_flobject_expression_integration.py Tests protocol rendering, validation, and parsed-expression compatibility. src/ansys/fluent/core/solver/flobject.py Adds generic expression handling and quantity validation to settings setters. src/ansys/fluent/core/offline/expressions/_ast.py Exposes expression rendering, kind, and dimension metadata. src/ansys/fluent/core/offline/expressions/__init__.py Updates the example to assign expression objects directly. doc/changelog.d/5546.added.md Announces expression-object support in settings parameters.
Review effort: Max
The reason will be displayed to describe this comment to others. Learn more.
🟡 Changes recommended
Group updates and command arguments bypass protocol rendering and kind/dimension validation, leaving the new safeguards ineffective on these shared conversion paths.
builder.parse('-MakeVec(1, 2, 3)') produces a UnaryOp, which inherits Kind.SCALAR, so this hook reports "scalar" for a vector-valued expression. The new scalar Real setter consequently accepts and renders it, although it correctly rejects the unnegated vector. Please preserve the operand's settings kind for unary expressions so negation cannot bypass structural validation.
Preserve empty mappings for dimensionless variables
For a descriptor with an empty dimension mapping, this truthiness check returns None instead of {}, treating a known dimensionless variable as unknown. Such a variable can then be assigned to a pressure-valued leaf without the intended dimensional rejection. Check dimension is None so an empty mapping remains dimensionless.
The reason will be displayed to describe this comment to others. Learn more.
🟡 Changes recommended
Unresolved issues let dimensionless and negated-vector expressions bypass validation and cause protocol-based filename arguments to fail in pre-execution file hooks.
Negating a vector changes its reported settings kind to scalar because UnaryOp inherits ScalarExpr, so a Real leaf accepts -MakeVec(...) even though it rejects MakeVec(...). Forward UnaryOp.__settings_kind__ to its operand and add a regression test for negated vector assignment.
Treat empty dimension mappings as known dimensionless
An empty descriptor dimension mapping is known dimensionless, not unknown. This truthiness check returns None for dimension={}, so a dimensionless variable bypasses validation against a pressure-valued leaf; the equivalent mapping {'LENGTH': 0.0} correctly normalizes to {} and is rejected. Check explicitly for None so empty mappings retain their dimensionless meaning.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
github-actions
Bot
added
the
documentation
Context
Let users assign expression-builder objects (and any object implementing a small protocol) directly to settings leaves — e.g. named_expressions["dp"].definition = dp instead of = str(dp) — with automatic validation, across every assignment path.
Change Summary
Generic, Fluent-agnostic protocol in the settings layer:
exprusable wherever an expression string is permitted:Quantity-type checks before str conversion:
__settings_kind__, and__settings_dimensions__. Quantity derives dims from its units; Variable from its VariableDescriptor.dimension. fluent_expr stays as the package-internal renderer.Impact
users assign expression-builder objects directly to settings leaves — e.g. named_expressions["dp"].definition = dp instead of = str(dp) — with automatic validation.
##Note:
When running against a live session: the dimensional check depends on ansys.units being able to resolve the leaf's SI unit string and the expression's units; anything it can't resolve is treated as "unknown" and tolerated, so it will never spuriously block a valid assignment.
Also added two parametrized tests in test_flobject_expression_integration.py implementing the requested flow — start from an expression string → parse via the builder → read the built object's quantity type → compare with the target parameter's quantity type.
For detailed plan of this please refer the issue and the tests as well